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Voorwoord 
BSO/Buro voor Systeemontwikkeling bv bestaat uit circa 450 medewerkers 
die verdeeld zijn over drie divisies. Een van deze divisies is 


BSO/Automation Technology bv. 


BSO/Automation Technology bv (AT) is gespecialiseerd in wetenschappelijke, 


industriële en technische automatisering. 


De projecten hebben onder meer betrekking op procesbestur ingssystemen, 


simulatie, computergraphics en computernetwerken, bijvoorbeeld : 
1) Ontwikkeling van proces simulaties in de petrochemische industrie. 
2) Ruimtevaartuig simulatoren t.b.v. opleiding van operators. 


3) Het leveren van tools t.b.v. het ontwerp van o.a. ruimtevaartuigen 


(Computer Aided Engineering). 


4) Modelling van desynchronisatie van spontaan actieve cellen in 


hartspieren. 
5) Simulatie van pijplijn en pomp configuratie. 
6) Modelling van staalfabriek processen om parameters te optimaliseren. 
7) Simulatie van steenkool vergassingsprocessen. 
8) Simulatie van radar omgeving t.b.v. personeelstraining. 
9) Röntgen simulator t.b.v. hardware onderzoek. 


10) Simulatie van een supersonische vlucht om thermische en mechanische 


analyses te verrichten. 


BSO/Management Support bv (MS) is betrokken bij het gebruik van modelling 


en simulatie bij economische en beslissingsondersteunende toepassingen. 
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Le SIMULATIE VAN PROCESBESTURINGSAPPARATUUR 
TEN BEHOEVE VAN SYSTEEMTEST 


M. Noordewier 
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Introductie 


Aan de hand van een praktijkvoorbeeld, te weten een bankbiljetten- 
sorteersysteem, wordt aangetoond hoe dit proces gesimuleerd kan 


worden en wat de voordelen van deze simulatie zijn. 





Inleiding 


In opdracht van De Nederlandsche Bank heeft BSO/Automation 
Technology bv software ontwikkeld ten behoeve van de besturing van 
een bankbiljettensorteersysteem. 


Uitgangspunten voor de ontwikkeling waren de volgende: 


= de computerapparatuur diende van Digital Equipment te zijn. De 


keuze is gevallen op een PDP11/44 en VAX11/730; 


— als sorteermachine is, door De Nederlandsche Bank, gekozen voor 


een Toshiba systeem; 


= de detectoren werden op specificatie van De Nederlandsche Bank 


door TNO/TPD (Technisch Physische Dienst) ontwikkeld. 
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G) Standaard DEC hardware 





(2) Standaard Sorteersysteem (Toshiba) 






(3) Customer specified detectoren (TNO/TPD) 
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1.2. Het Systeem 


Teneinde van de losse componenten één systeem te bouwen waren de 


volgende activiteiten nodig: 

= de VAX diende voorzien te worden van een database systeem; 
= de PDP diende voorzien te worden van besturingssoftware; 

= VAX en PDP dienden on-line gekoppeld te worden: 


= de PDP kreeg interface hardware voor koppeling met de 


sorteermachine en detectoren; 
= de sorteermachine diende voorzien te worden van een interface 
voor externe besturing. Aanpassing was nodig in zowel hardware 


als software van de interne TOSBAC computer; 


- de detectoren dienden geïntegreerd te worden met de 


sorteermachine. 
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Planning 


In de planning zijn 3 parallelle paden te onderscheiden: 


l) modificaties aanbrengen aan sorteersysteem. 


Plaats van handeling: Tokyo, Japan. 


2) ontwikkeling detectoren. 


Plaats van handeling: Delft 


3) ontwikkeling database en besturingssoftware, 


Plaats van handeling: Utrecht 


In november 1983 werden 3 systeemdelen overgebracht naar De 
Nederlandsche Bank te Amsterdam. 

In een periode van circa 6 weken werden de delen geïntegreerd, 
werkend gemaakt en het systeem werd 'getuned'. 

In de volgende 3 maanden, de systeemtest periode, werden 


betrouwbaarheidstesten en performancetesten uitgevoerd. 


PLANNING 


1985 1984 


| JAN,FEB,MRT, APR, MEI,JUN,JUL,AUG,SEP,OKT,NOV,DEC | 


SW | specs | implementatie integratie systeem test 
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Knelpunten 


- Gezien de hoge snelheidseisen die aan het besturingssysteem 
gesteld werden, bestonden bij BSO grote twijfels of een PDP11/44 
onder operating system RSXÌll-M voldoende snel zou zijn. 

De eisen aan het sorteersysteem zijn: 
5 sorteersnelheid 14 biljetten /sec. (70 msec./biljet):; 
° er mag nimmer een bankbiljet 'zoek' raken in het systeem; 


5 de uurproduktie moet minimaal 36.000 biljetten zijn. 


- Tijdens de specificatie van de interface tussen de 
sorteermachine en het besturingssysteem bestond een beperkt 
inzicht in de informatie die uit de sorteermachine benodigd was, 
de mogelijkheden om deze informatie te verkrijgen en de wijze 
waarop synchronisatie tussen de sorteermachine en de PDP 
gerealiseerd zou moeten worden. 


Vroegtijdige informatie hieromtrent was dus wenselijk. 


= Communicatie tussen Nederland en Japan is niet zo eenvoudig, 


vanwege taal, volksaard, afstand en tijdverschil. 


— zodra alle componenten beschikbaar waren, diende zo snel 


mogelijk de betrouwbaarheidstesten te starten. 


Een en ander resulteerde in het voorstel om twee simulatoren te 


bouwen: 
l) een simulator van het besturingssysteem; 
2) een simulator van het sorteersysteem inclusief 6 detectoren. 


Beide simulatoren zijn gerealiseerd op een PDP1I1/23+ onder 


operating system RSX1l-M. 
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Besturingssimulator 


De besturingssimulator bestuurt de interface naar de sorteermachine. 
Via een terminal kunnen commando's of een serie commando's naar de 
interface gestuurd worden. De status van de sorteermachine wordt 
teruggelezen en weergegeven. Nadat het systeem in Utrecht getest 
was is het stuk interface hardware en de software naar Japan 
verstuurd. 

Toshiba had inmiddels een PDP11/23 systeem aangeschaft waarop de 
interface werd aangesloten en de simulator software gedraaid kon 
worden. Met dit systeem is circa 6 maanden voordat de 
sorteermachine naar Nederland kwam, de interface getest. 

In een vroeg stadium werd dus duidelijkheid geschapen en vertrouwen 


gewekt in het interface ontwerp. 





Simulatoren (1) 





— besturings simulstor 


| 
— deze simulator is naar Japan gestuurd | 
om interface hardware in sorteersysteem 

te testen | 
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EIGENSCHAPPEN SIMULATOR 
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Simulator sorteersysteem 


De tweede simulator, die voor dit project gebouwd is, gedroeg zich 


als een sorteermachine met 6 detectoren. Via een toetsenbord konden 


variabelen als: 


bankbiljet serienummers, 
aantal te sorteren biljetten, 
detector resultaten en 


sorteersnelheid 


worden ingevoerd. 


Teneinde de koppeling met de besturingsmachine te realiseren is een 


standaard interface rack gemodificeerd. 


Het systeem is gebruikt om de volgende testen uit te voeren: 


hulpmiddel bij module en integratie testen, waarbij op zeer lage 
snelheid testdata werd aangeboden. Hierdoor kan de logica van 
programma's alsmede algoritmen getest worden; 

doordat de testdata volledig bekend en reproduceerbaar was 
konden testen, na modificaties in de te testen software, 
herhaald worden; 

nadat de logica van programma's correct was, kon op nominale 
snelheid getest worden. Op deze wijze is een 'in-house' 
systeemtest uitgevoerd; 

door de snelheid verder op te voeren kon gestest worden wat de 
maximale capaciteit van de PDP/44 was. 

Bij een cyclus tijd van 56 milliseconden bleken problemen te 


ontstaan. 


Belangrijke problemen die vroegtijdig ontdekt werden waren de 


volgende: 


de full duplex terminal driver van RSX gaf zoveel overhead dat 
de maximale snelheid van het systeem circa 9 biljetten per 
seconde mocht zijn (66%). De oplossing voor dit probleem werd 
gevonden in het volgende: 

. eigen driver voor communicatie met VAX; 


e eigen driver voor communicatie met detectoren. 


=id 
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- de interne klok periode van het systeem mocht niet lager dan 6 
milliseconden zijn. Als veilige waarde is 8 milliseconden 
gekozen. Dit is de resolutie in tijd waarin de synchronisatie 


van het systeem gecontroleerd wordt. 


Echter ....... 


Bij gebruik van de simulatoren dienden de volgende kanttekeningen 


te worden gemaakt: 


l) een simulator is een benadering van de realiteit, Hoe goed deze 


benadering is kan vooraf meestal niet bepaald worden. 


2) voor het testen van de ene simulator was eigenlijk een werkend 
besturingssysteem nodig, voor de andere een werkende 
sorteermachine. Beide waren niet beschikbaar. Voor het testen 
van beide simulatoren zijn deze aan elkaar gekoppeld en, met 
veel nadenken over het feit of een probleem in het ene of het 


andere systeem moest worden opgelost, werkend gemaakt. 
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Resultaten 


Door toepassing van genoemde simulator systemen zijn de volgende 

resultaten bereikt: 

= in een vroeg stadium is duidelijkheid verkregen over het 
interface tussen sorteersysteem en de PDP; 

= real-time testen zonder werkelijke sorteermachine konden 
plaatsvinden, resulterend in een in-house systeemtest; 

= er konden performance testen worden uitgevoerd; 

= de integratie en 'on-site' systeemtest fase zijn aanmerkelijk 
bekort; 

- tijdens de 'on-site' systeemtest Éase kon parallel gewerkt 
worden aan de oplossing van problemen in de sorteermachine en in 
de software; 


= doordat de software grotendeels was uitgetest kon de integratie 


en de systeemtest met beperkte mankracht worden uitgevoerd. 








RESULTATEN 


— in vroeg stadium duidelijkheid over 
interface PDP-sorteersysteem 






— real-time simulatie mogelijk 






— door opvoeren van snelheid kon 






overcapaciteit aan besturingssysteem 






bepaald worden 






— _na koppeling van sorteermachine aan 






besturingscomputer werkte het systeem 






binnen 2 dagen 






— integratie met detectoren en systeemtest 





kon gereduceerd worden tot 3 maanden 
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AN ARCHITECTURE FOR REAL-TIME SIMULATION 
OF INDUSTRIAL PLANT 


A. Lynch 
BSO/Automation Technology bv 


Abstract 


A simulator of industrial plant replaces the real plant at its 
connection to a SCADA system. 

Operators can then be trained in the use of the plant, using the 
real SCADA system. 
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Introduction 


Scope 


An industrial plant has been provided with a computer control and 
monitoring system, a SCADA system, in addition to the standard 
local manual controls. Operation of the plant, through the use of 
the SCADA system, is entrusted to an operator who is responsible 


for plant operation under both normal and emergency situations. 


A high degree of operator familiarity with the plant is therefore 
required, and subsequently a simulator to model the operation of 
the plant was proposed, essentially to assist in the training of 


operators. 


Operator training is normally carried out in training sessions 
under the supervision of an instructor. The simulator must 
consequently provide the instructor with facilities to define plant 
characteristics, to specify the format and contents of training 


sessions, and to monitor trainee progress. 


A simplified diagram showing the relationships between the 
instructor, the trainee, the simulator, the SCADA system, and the 


actual industrial plant is presented in figure one. 


An important consideration is that the simulator emulate only the 
industrial plant, that is, the simulator should interface to, but 
not model, the SCADA system. In this manner, the operator (and the 
SCADA system) need not be aware that the simulated plant is not a 
real plant. As a consequence, the simulator must be sufficiently 


realistic such that the actual plant appears to be present. 
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2.2. 


Requirements 


Three types of requirements must be satisfied by the simulator, in 


particular, 


Trainee requirements: 


a fundamental objective is that the trainee should detect no 
perceivable difference between operating the simulator and 
operating the plant. A trainee operator controlling the simulator 
must be able to perform all the functions of an operator 
controlling the plant, within the context of a particular training 
session. Similarly, the simulator must respond to trainee commands 


with the expected behaviour of the actual plant. 


Instructor requirements: 


Appropriate facilities must be provided to enable the instructor to 


define and control training sessions. These facilities include: 


plant configuration = defining the participating parts of 
equipment within the plant, their 
relationship with each other, and the 
level of modelling detail required for 


each part; 


training scenarios — specifying sets of pre-determined events 
to be actioned within given training 


sessions ; 


simulation control = control of the training session, that is, 
starting/stopping the simulator, 
initialisation of the simulator to 
selected states, simulation speed control, 


and enabling or disabling replay/recording; 


monitor selection = examination of equipment characteristics 
during training sessions to monitor 


trainee progress, and simulator state. 
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Software requirements: 


the simulator is to be developed on a VAX 11/782, a dual-processor 
machine. However, the VAX is merely the development machine and it 
is intended that the simulator, once proven to operate on the VAX, 
shall be implemented on two Ferranti Argus 700 GX computers. As a 


result, two important design constraints must be applied: 


= the simulator should, as far as possible, remain machine 
independent. Machine-specific software should be confined to 


clearly identifiable library functions; 


= the implementation language should be Fortran which is readily 


available on both the VAX and ARGUS machines. 


The overall intention is to prove that simulation of the industrial 


plant is possible, with the VAX, then implement the simulator on 


the ARGUS machines with the minimum of effort. 
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Figure one : Simplified Overall Configuration 
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2.3 Design Overview 


2.3.1 Process Overview 
er vervlew 


The design of the industrial plant Simulator is centred on the idea 


of a simulation executive process to control the real-time aspects, 


And a series of essentially parallel detached processes to perform 


the actual simulator functions. An overview of the individual 


Processes is presented in figure two, which are, in Particular, 


instructor facilities, 


simulation executive, 


transfer, 


which provides the instructor with the 
ability to define plant configurations, 
training scenarios, and monitor screens, 
together with simulation control. In 
Principle, the instructor facilities can 
run concurrently with the Simulation to 
enable the instructor to Prepare training 


Sessions for use later ; 


which controls the execution of the 
simulator from one ‘frame! period to the 
next, co-ordinating the Production of new 
results at every 'frame' interval. Its 
responsibilities include enabling the 
equipment models to run, controlling the 
transfer of data between the simulator the 
SCADA system, and responding to instructor 


requests; 


which emulates the Protocol to the SCADA 
System, that is, the Process controls all 
communication between the SCADA system and 
the simulator. Trainee commands and 
console control Signals are received Êrom 
the SCADA system, and simulation results 


are returned; 
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record and playback, which is responsible for the storing of 


monitor, 


plant models, 





Figure two 





simulation details from a training 
session, for example, model results and 
instructor commands, together with 
permitting simulation recordings to be 


replayed by the instructor; 


which is concerned with the display of 
simulation information on the instructor 
console. The information includes values 
of equipment variables (selected by the 
instructor) together with simulator status 
information (simulation time, state, 


messages) ; 


which contains the processes to simulate 
the individual parts of the plant 
equipment. The industrial plant is 
modelled by several 'segments', where a 
‘segment! represents a part of the plant 


such as a valve or a pipe. 


PROCESS OVERVIEW 
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Data Overview 


Several types of data may be recognized within the industrial plant 
simulator. The sets, as indicated in figure three, are classified 


as : 


configuration data, which specifies details of all possible 
configurations of the simulator. In 
particular, the configuration data 


determines: 


— all the model segments which may participate in a simulation 
together with relevant details for each segment, for example, 


required inputs and outputs; 


— all the simulation variables which the instructor may alter 


(that is, scenario events), or which the instructor may monitor; 


= all the simulation variables whose values are input Érom, and 


output to, the SCADA system. 


The principle of the simulator driven Êrom control tables 
(configuration tables) ensures that model segments may be changed 
without alteration to the simulator software, and also presents the 


possibility of extensions to the system. 


instructor data, which contains all the information created 
or generated by the instructor. All data 


is held in text files which may be: 


= scenario files, with one scenario per file. A scenario defines 
the operation of the simulator through a pre-determined series 
of events, each event specifying a particular action and a 


particular time of occurence; 


ZO 








model selection files, with one model selection per file. 
The model selection determines the level of detail of the 
individual model segments for a given simulation. All model 
segments are assumed to be present in all possible 
simulations, with the level of detail specifying to what 
degree a particular model segment participate (levels of 
detail range from 'full realism' to, effectively, 


non=-participating) ; 


monitor selection files, with one monitor ‘window! per 
file. Monitor selection provides a mechanism for the 
examination of variables within the simulator, that is, 
'state' variables. 

The outputs Érom the examination are arranged as 'state' 
variable information 'windows", each 'window' containing 


approximately one screen of information; 


record files, containing details and values of simulator 
‘state! variables recorded at intervals defined by the 
instructor. The information recorded for one interval is 


sufficient to reconstruct the simulation. 


transient data, which contains all the data generated 


internally by the plant simulator. 
All internal data is 'owned' by the 


simulation executive, and includes: 


the 'state vector', which completely describes the state of 
the simulator, for a given point in time. The state vector 
consists of approximately 128K elements, whose values are 
collectively referred to as a simulation 'frame'. All 
communicating processes within the system which require to 
transfer data, interface with the state vector but not with 
each other, thus preserving modularity and consequently 


flexibility of configuration. 


command buffers, and internal look-up tables which are 
required to enable conversion of the external configuration 
data for a selected model into an efficient internal form 


for subsequent simulation of the plant. 


- 22 — 





figure three : Data Overview 
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Detailed Design 


The simulation executive 


The simulation executive is responsible for the control of those 
tasks which access the state vector. It must ensure that the model 


segments are enabled in the correct order, each updating that part 
of the state vector for which it is responsible, and synchronise 
the transfer of data between the state vector and both the SCADA 


system and the instructor facilities. 


Within the exective, two types of process may be recognized. The 
diagram in figure four identifies these types of process, together 


with their data interfaces, which are: 


— real-time, or ‘kernel' tasks, which must run at a specific 
period, receive all input data Érom the state vector, and return 


all output data to the state vector. 


= non=real-time, or 'shell' tasks, which run only when required to 


do so. In general, these tasks are responsible for handling the 
interfaces between the simulation executive and the other major 


sub-systems within the plant simulator. 


In the example of figure four, ‘event list compile' is a 'shell' 
task which accepts a new scenario Érom the instructor facilities 
and translates it into an efficient internal form. The new scenario 
is received via a mailbox, then compiled into an internal (core 
resident) command buffer. The 'event poke! is a 'kernel' task 
which, every frame, selects events from the command buffer which 
are valid for the current frame, and transfers these events to the 


state vector. 
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The 'state vector! 


The 'state vector' forms the principle means of data communication 
among the real-time ('kernel') tasks under the control of the 
simulation executive. The three distinct areas within the state 


vector, as indicated in figure five, are: 


output area, which contains, for each task, an area 
reserved for the results generated by that 
task which are required as inputs to other 
tasks, that is, interface variables. 
Outputs from a task are allocated 
contiguous locations in the state vector. 
An important consideration is that all 
inputs for a 'kernel' task are formed only 


from the outputs of other 'kernel' tasks; 


constant area, which contains, for each task, an area 
reserved for configuration/initialisation 
constants. These values include, for 
example, in the case of model segments, 
equipment operating ranges, dimensions, 


and initial settings; 


private area, which contains, for each task, an area 
reserved for internal task variables. 
Unlike the constant and output areas, the 
private area for a task may be variable in 
size dependent on level of detail selected 
for the task (only model segment tasks 


have selectable levels of detail) 


Access to the state vector by 'kernel' tasks can only be performed 
through the use of two state vector access routines, one to 


retrieve data for a specific task from the state vector, and ane to 
return data for a specific task to the state vector. The access 


routines handle all state vector access details, and a task merely 
specifies a task identifier and the type of data (constant, 


private, output) to be transferred. 


The state vector, the general access routines, and required state 
vector addrsss look-up tables all reside within the VAX/WMS system 
a shareable, installed image. This feature provides a relatively 


fast, easy and secure method of data storage and retrieval. 
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figure four : Simulation Executive Processes 
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figure five : State Vector Structure 
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Real-time Task Structure 


A scheduler process exists within the simulation executive which is 
responsible for enabling 'kernel' tasks to run in the current frame 
by granting those tasks access to the state vector. Each task which 
requires access to the state vector has two associated event flags 


(VAX/VMS event flags): 


grant flag, from which the task may determine if 
access to the state vector has been 


granted by the scheduler ; 


release flag, with which the task can indicate to the 
scheduler that it has completed its 


required state vector accesses. 


If a task requires state vector access, it must wait until its 
associated grant flag is set by the scheduler. When the task is 
granted access, it first resets the grant flag then performs the 
desired state vector accesses (through the use of the data access 
routines). On. completion of state vector access, the task sets its 
release flag to indicate to the scheduler that the task has 


finished with the state vector for the current frame. 


The ‘kernel' tasks, as far as the scheduler is concerned, fall into 
two categories, namely, synchronous tasks (that is, tasks which 
require exclusive access to the state vector), and asynchronous 
tasks (that is, tasks which may operate with shared state vector 
access). A task run order is defined such that all synchronous 
tasks are enabled first, in a specified order, one at a time. After 
the last synchronous task has completeá its state vector access, 


the asynchronous tasks are enabled, in an arbitrary order. 
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The scheduler, dependent on the task type, has two methods of 


handling state vector release flags: 


with synchronous tasks, having granted access to the state 
vector to a particular task, the scheduler is suspended pending 


the setting of the release flag for that task; 


with asynchronous tasks, having granted access to the state 
vector to aìl tasks, the scheduler is suspended pending the 


setting of all the complete flags for those tasks. 


The structure of a typical 'kernel' task is depicted in figure six. 
An important feature of the design is that the task, having been 
granted access to the state vector, first returns results to the 
state vector from its previous calculation step, then accepts 
inputs for the next calculation step. In this manner, the scheduler 
wait time, and hence the time required to enable the remaining 
tasks in the current frame, is reduced to a minimum. Another 
important factor is that although all the 'kernel' tasks are 
enabled according to the order specified by the scheduler, each of 
the tasks specifies its own frequency of call. When data is 
returned to the state vector, a task also indicates it desired next 
time of call which the scheduler accepts and incorporates into the 
task run order. Therefore, for example in the case of the model 
segments, the complexity of increasing/decreasing the time steps at 


critical points may be built into the individual models. 
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Summary and Conclusions 


In conclusion, the characteristics of the design of the industrial 


plant simulator are: 


= the system consists of several essentially independent process 


tasks which may communicate with each other in real-time; 


= all real-time processes have the same type of interface and 
communicate solely with the simulation executive and state 
vector, not with each other. This promotes the concept of 


modulartity and flexiblility of the system; 


- all equipment model processes have been treated as 'black boxes ' 
by the simulation environment thus details of model intelligence 


have been restricted to one area; 


- the state vector consolidates process independence as tasks have 
no need to know where input and output data is located. In 
addition, the state vector access routines hide system dependent 
store addressing, therefore may be optimised for particular 


systems; 


= the interface with the SCADA system has been clearly defined 
therefore, apart from the interface process, the remainder of 


the simulator system need not know details of the SCADA system; 


— similarly, the clear distinction between the instructor 
facilities and the actual simulator presents an opportunity to 
use, for example, 'standard' software, that is, perhaps a menu 
system for the instructor interface, or a modest database system 


for instructor data/configuration data. 
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Program kernel—task-—structure 


do while (end-simulation .eqv. .false.) 


call svwait (task—no) wait for scheduler to set grant 
flag for task 


cali svwrite (task—no) write results of previous step to 
state vector 


call svread (task—-no) read inputs for next step 

cail svrelease (task—no) set release flag for task to 
indicate to scheduler that task 
has finished with state vector 


(calculations for one step) 


end do 


end program 
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SATELLITE SIMULATOR FOR SOFTWARE 
COMMISSIONING AND TRAINING 


L. Killick 
BSO/Automation Technology bv 


Abstract 


A simulator replaces a satellite and its telemetry link to the 
ground station in order that ground support software can be fully 
commissioned and operators of a satellite can be trained before the 


satellite is launched. 
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3.1. 








Introduction 


The European Space Operations Centre (ESOC) situated in Darmstadt, 
West Germany, is the Operations Centre of the European Space Agency 
(ESA) from which control of a number of satellites and their 
associate groundbased control and traking equipment is maintained, 


The central computer system used for satellite control is known as 


‘ the Multi Satellite Support System (MSSS), wich consists of a 


GOULD/SEL 32/67 processor with 6 M-byte main memory with 2304 

(9 x 256) M=-byte of disc storeage available. The disc storeage is 
shared with an identical configuration which is used for 
development work, but which can also be switched in as the 
real-time control machine within a few minutes. These computers are 
linked by an X-25 based Data Packet Switching System (DPSS) both to 
other equipment at ESOC and to the worldwide network of 


groundstat ions. 


(Fig. 1: Multi-Satellite Support & 
Simulation Computer Systems at ESOC) 
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1: SATELUTE SUPPORT & SIMULATION 
COMPUTER SYSTEMS AT ESOC 
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Before a satellite is launched it is essential to test that all 
ground systems involved in the support of the satellite control are 
functioning correctly. In particular the complex functions at ESOC 
in both the manual and computer operations required to monitor and 
control the launch and early orbit phases of a satellite mission 
and the procedures used for the support of the satellite throughout 
its lifetime, must be tried and Practised many times for some 
months before a launch takes place. Additionally a training 
facility is required for new satellite operations controllers and 


‘refresher' courses for existing staff. 


Since 1975 ESOC has used real-time software satellite simulators in 
a dedicated computer communicating with the MSSS by simulated 
telemetry and telecommand messages. The present configuration 
consists of a GOULD/SEL 32/7780 with 2 M-byte main memory and 256 
M-byte disc, with which it is possible to support up to two 
satellite simulations simultaneously. Currently six ESA satellites 
(already launched) are available as simulations, with two new 
models in development and three more, in the early specification 
stage. 


(Fig. 2: Simulator replacing the ground 


station and satellite in the ESA environment) 
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FIG. 2: _ SIMULATOR REPLACING THE GROUND 
STATION AND SATELLITE IN THE ESA 


ENVIRONMENT 
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General Purpose Satellite Simulation Package 


Satellite simulators are interfaced to the MSSS at the level of 
messages which would normally be passed between the MSSS and a 
ground station. In this way the simulator appears to the MSSS as 
one or more ground stations of the ESA network. This means that the 
simulation is not only of the satellite and its environment, but 
also must include a partial simulation of the ground station 
equipment which normally supports the satellite/OCC communications. 
As such items as satellite environment, ground station equipment 
and simulator control do not vary conciderably between satellites 
ESOC has developed a software package which provides a basic 
framework to which a specific satellite model can be interfaced. 
This is called the General Purpose Satellite Simulation Package 
(GPSSP) . 


GPSSP is written principally in SEL Fortran 77+ to run on a SEL 
32/77 with MPX V2.1l operating system. The package consists of 
software to generate a simulator which consists of four concurrent 
tasks in the SEL computer, communicating with each other by means 
of a global common database and MPX interrupt and message handling 


facilities. These tasks are known as: 


= interactive task (INTK) which handles all simulation commands 


from the simulation officers console; 


= support task (SUPP) responsible for decoding user commands 


received by INTK, handling the simulation log and most disc 1/0; 


= ground task (GRND) which interfaces to the DPSS network and 


simulates the ground station activities of buffering and 
formatting satellite telemetry into ESOC standard messages, and 
receiving telecommands from MSSS and passing them on to the 


Sspacecraft model; 


= kernal task (SKRN) which contains the event scheduler, and 


simulates advancing time and the corresponding changes to the 


satellite and its environment. 
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Fig. 3: Simulator tasks and database 


FIG. 3: 
SIMULATOR TASK AND DATABASE 
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The Interactive Task 


The interactive task is primarily in a timed wait state, Êrom which 
it exits at regular intervals to update the simulation officer's 
console screen. It can also be interrupted from the wait state to 


receive command input form the simulation officer. 


The interactive task is part of GPSSP and standard to all 


simulations. 


Fig. 4: The Interactive Task 


SCREEN UPDATE 


FIG.4: THE INTERACTIVE TASK 
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The support task 


The support task is held in a wait state Pending an interrupt from 
another task to indicate that some action must take place, or an 


operator command must be interpreted. 


The support task is part of GPSSP and standard to all simulations 
with the exception of a few routines which are supplied with each 


satellite model (mainly for error message logging) 


Fig. 5: the Support Task 
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FIG. 5: THE SUPPORT TASK 
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The Ground Task 


The ground task is continually receiving telemetry generated by the 
satellite model in the kernel task, and is additionally interrupted 
by the receipt of telecommands in the form MPX messages which have 


been sent from the spacecraft controller in the OCC. 


Ground station simulations vary for each simulator, GPSSP provides 


a framework from which a particular simulation can be developed. 


Fig. 6: the ground task 
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FIG. 6: THE GROUND TASK 


— BSO/Automation Technology Simdag 





=S 2 





3.6. The Kernel Task 


The Kernel Task is by far the most complex area of the simulation; 
it is subdivided into three sections each of which may be developed 
separately, given that there is a clearly defined interface between 
them. 


Satellite and environment models are usually designed by spacecraft 
engineers, either on-site at ESOC or possibly by the satellite- 
manufacturers. The telemetry encoder is not a model of an actual 
piece of equipment, but is a software solution to the problems of 
Providing a simple means of defining telemetry format and updating 
telemetry parameters from the satellite model, and of supplying 
telemetry in the correct order and correct speed to the ground 
station simulation. The telemetry encoder is a standard piece of 


GPSSP, but needs to be configured for each satellite simulation. 


Fig. 7: the kernel task 
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FIG.7: THE KERNEL TASK 
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The control section is standard to all simulations and forms the 
heart of GPSSP where the simulation is synchronised witn real=time, 
certain operator commands are executed, and telecommands are 


forwarded to the satellite model. 


Fig. 8: GPSSP control section 








operator 





encoder 


SCHEDULER 






command 







actions 





SATELLITE 
GRND MODEL “REAL TIME" 


FIG.8: GPSSP CONTROL SECTION | 
BSO/Automation Technology Simdag 







— 40 — 








The scheduler contains a list of actions which must be activated at 
a given time. The time may be "immediate", at some future specified 
time, or “pending” (to be activated when there is spare time). The 
basis of the simulator is that most actions when completed 
reschedule themselves for reactivation at some future time, and 
sometimes schedule additional actions. 

The GPSSP control section itself schedules two actions, the 
simulator's synchronisation with real-time and a regular polling of 
the OCC-telecommand and simulator operator command interfaces. 

Also the telemetry encoder is scheduled at regular intervals 
(dependant an the simulated bit-rate required) but this is achieved 


outside of the action list kept by the scheduler. 


In principal the simulation is always ahead of real-time, the next 
action on the schedule being performed and simulator time being 
updated to the time of the requested action, until a SYNC request 


is met = then the SYNC action waits for "real-time" to catch up. 


Fig. 9: GPSSP event scheduler 
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FIG. 9:THE GPSSP EVENT SCHEDULER 
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FIG. 9A: THE GPSSP EVENT SCHEDULER 
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Simulator Operation Overview 


The simulator is usually commanded by a Simulation Officer who will 
use the commands provided by GPSSP to set the satellite model into 


a particular situation — this includes Buch details as: 


— mission phase e.g. launch 
early orbit 
on station (e.g. geostationary communication 
Satellites) 
normaì orbit, encounter 


(e.g. scientific mission, giotto) 
- date, time 
- satellite position on the orbit and satellite attitude 
—- the ground station(s) in use 


- telemetry type(s} transmitted, and the time-labels attached to 
them 


= spacecraft or ground station failures (faulty equipment). 


The Simulation Officer can then monitor the progress of the 
Simulation via a normal computer terminal = it is possible to 
inspect any data item from the global common database, these 
include both internal simulation model parameters and the telemetry 
parameters which are being transmitted to the MSSS. A simulator log 
can also be displayed showing significant events that take place 
including the state of the communications links, records of 
telecommands received, and a record of all commands entered by the 


Simulation Offficer. 
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In another location in the OCC the spacecraft controller(s) are 
using their normal equipment to monitor the satellite status and to 
prepare and transmit commands to the satellite. Voice links are 
maintained with ESA's own voice-communication network; in this way 
the Simulation Officer may also play the part of a station 
operator, responding when requested by the spacecraft controller to 
modify the ground station configuration or to send verbally given 
telecommands to the satellite in the case of a simulated 


communications failure or otter problem. 
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Fig. 
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10: GPSSP Operator Commands 


save simulator database 

insert a command into spacecraft 
simulator control 

hardcopy screen contents 

set the current simulated epoch 
set/reset spacecraft failure 

define a display group 

identify current ground station 
set orbit parameters 

run a file of simulator commands 
ranging request 

restore the database saved by BREA 


FIG. 10: GPSSP operator commands 
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examine simulation log 

show a display group 

sweep carrier uplink 

uplink a command frame 

set TC uplink chain 

set operations time 

select telemetry message format(s) 
execute a special effect 

set ground station coverage 


FIG. 10A: GPSSP operator commands 
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4. SIMULATIE VAN DE UTILITY STROMEN 
IN EEN BIERBROUWERIJ 


H. van Eggelen 
BSO/Management Support bv 


Introductie 


Voor Heineken Technisch Beheer is een simulatiemodel ontwikkeld van 
de energieverbruikers van de Heineken brouwerij. 

Allereerst volgt een inleiding over het brouwproces, de 
doelstellingen en verwachtingen alsmede de realisatie van het 


geheel. Tevens worden een aantal conclusies getrokken over 


doelstelling en gevolgde werkwijze. 
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4.1. Simulatie van de utility stromen in een brouwerij 


Op de afdeling Simulatie Techniek binnen Heineken Technisch Beheer, 
is een simulatiemodel van de energieverbruikers van de Heineken 
‘brouwerij te Zoeterwoude ontwikkeld. Het model bootst de 
energiestromen na en houdt de energievragen en verbruiken bij, o.a. 
in de vorm van een Elektriciteit/Stoom (E/S) matrix (deze matrix 
wordt verderop nader besproken) . Achtereenvolgens worden een aantal 


aspecten van dit simulatieproject behandeld. 


Eerst volgt een inleiding over de afdeling zelf en haar 
activiteiten, over het model Utility - Stromen en over het 
brouwproces. Laatsgenoemde inleiding is meer bedoeld als 
achtergrondinformatie. Vervolgens komen de aanleiding tot de 
ontwikkeling van het model en de doelstelling van het model aan de 
orde, gevolgd door een opsomming van de verwachtingen die men van 


het model had en de gerealiseerde toepassingen. 
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Karakteristieken van de simulatietaal PROSIM, Waarin het computer- 
simulatiemodel is geschreven, en de systeemomgeving waarin het 
model is ontwikkeld, worden in het kort besproken. 

Er wordt aandacht besteed aan het bereikte eindresultaat en hoe het 
model in de praktijk wordt gebruikt. Met de E/S Matrix Kunnen 
verschillende berekeningen worden verricht. Eén zo'n berekening 
waarvoor afzonderlijke programmatuur is ontwikkeld wordt nader 
uiteengezet, 

Tenslotte worden enkele conclusies over het project besproken ten 


aanzien van de doelstelling van het model en de gevolgde werkwijze, 
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Inleiding 


De afdeling Simulatie Techniek is een onderdeel van Heineken 
Technisch Beheer (H.T.B.). H.T.B. kan worden omschreven als het 
ingenieursbureau van Heineken. H.T.B. verricht verschillende 
onderzoeken en voert allerlei projecten uit voor de 
produktiebedrijven, de brouwerijen, van Heineken. H.T.B. 
onderscheidt zich van andere ingenieursbureaus door de specifieke 
brouwerijkennis die het in huis heeft. H.T.B. bestaat uit een 
aantal afdelingen, waaronder verpakkingstechniek, procestechniek, 


utilities & milieu, simulatietechniek. 


Binnen de afdeling Simulatie Techniek worden verscnillende 


simulatiemodellen ontwikkeld en beheerd. Enkele voorbeelden zijn: 


- universeel colonne model 
(berekent rendementen, bufferbezettingen en 
besturingskarakteristieken van colonnes); 
— utility stromen model 
(berekent E/S matrix, piekverbruiken, energievragen per 
brouwerij onderdeel) ; 
- produkt stromen model 
(berekent bezettingsgraden, doorlooptijden, wachttijden, reserve- 
atelïisgen): 
— kleppenmatrix model 
(berekent stagnaties in filtratieproces, uitwijkcircuits); 
- pasteur simulatie model 


(berekent warmte/water balans) . 
Daarnaast worden tevens ondersteunende systemen vervaardigd, 


bijvoorbeeld voor gebruikersvriendelijke invoerverzorging van een 


specifiek simulatiemodel. 
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Het project "Simulatiemodel van de Utility Stromen in een 
Brouwerij" is in 1981 opgestart. Eerst hebben achtereenvolgens twee 
afstudeerstudenten van de onderafdeling der Wiskunde van de 
Technische Hogeschool te Delft, in het kader van hun 
afstudeeropdracht, de eerste aanzet gegeven en het Model in een 
vergevorderd stadium gebracht. Vervolgens heeft de verdere 
ontwikkeling ruim een jaar stilgelegen, waarna de beslissing 
genomen werd het model niet alleen af te ronden, maar tevens om te 
zetten naar de nieuwste versie van de gebruikte simulatietaal. Deze 
nieuwste versie was niet upwards compatible met de vorige versies, 
door een aantal grondige wijzingingen, hetgeen tot een conversie 
van het model noodzaakte. 

BSO/MS heeft meegewerkt aan deze conversie en de voltooiing Van het 
utility model. Bovendien heeft zij afzonderlijke programmatuur 
ontwikkeld waarmee weer berekeningen met de simulatieuitvoer kunnen 


worden verricht. 


Daar het model Utility Stromen alle energieverbruikers van de 
brouwerij Zoeterwoude omvat en dus het gehele brouwproces is 
gemodelleerd, volgt eerst nog een beknopte beschrijving van dit 


brouwproces ter informatie, 


INLEIDING 


— AFDELING SIMULATIETECHNIEK 


o PLAATS BINNEN HEINEKEN 


o ACTIVITEITEN / PROJECTEN 


— HET MODEL UTILITY-STROMEN 


== HET BROUWPROCES 
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Het brouwproces 


Hieronder volgen de belangrijkste deelprocessen van het 


brouwproces, Elk deelproces wordt kort beschreven: 


— _Mouten 


Eén van de grondstoffen van het bier is het mout, Mout wordt 
verkregen door gerstkorrels te laten ontkiemen en zodra de 
kiemblaadjes tevoorschijn komen dit proces abrupt te beëindigen 
door de gerstkorrels te eesten. Eesten is het verwarmen van de 
korrels met behulp van warme lucht. Doel van het mouten is de 


kiemen enzymen te laten produceren. Gerst mouten duurt ongeveer 


negen dagen. 


—- Brouwen 


Een hoofdonderdeel van het brouwproces is het eigenlijke brouwen 
en vindt plaats in het brouwhuis. Het doel van het brouwen is 
het in oplossing brengen van alle gewenste bestanddelen van mout 
en hop. In dit brouwproces kunnen de volgende stappen 


achtereenvolgens worden onderscheiden: 


= het malen (schroten) van het mout; 

zi het beslaan van het schroot met water en het zodanig 
opwarmen van dit beslag dat de enzymen het zetmeel in suiker 
kunnen omzetten; 

e het scheiden van het gevormde extract en de oplosbaar 
gebleven bestanddelen; 

= het koken van de oplossing (de wort) met hop. 


Dit brouwproces neemt ongeveer negen uur in beslag. 
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Koelen 


De hete wort moet gekoeld worden omdat de gist het beste werkt 
bij een temperatuur tussen de 6 en 10 graden Celsius. Warme wort 
en koud water stromen in gescheiden systemen en in tegenoverge- 
stelde richting langs elkaar. De wort koelt af en het water 
wordt warm. Dit warme water wordt weer in het brouwhuis benut 
voor volgende brouwsels. Het koelen van de wort duurt ongeveer 


één, hooguit twee, uur. 


Vergisten 


De vergisting is de volgende belangrijke stap in het brouwproces. 
De vergisting is het proces waarbij de suikers in de wort door 

de toegevoegde gist worden omgezet in alcohol en koolzuur. 

Tevens worden stoffen gevormd die smaak en kwaliteit beïnvloeden, 
De vergisting vindt plaats gedurende zeven tot tien dagen, afhan- 
kelijk van de biersoort, Aan het eind van de vergisting worat het 
ontstane “jong bier" tot het vriespunt afgekoeld en overgepompt 
naar grote tanks in de lagerkelder. De gist blijft achter. 


Lageren 


Het jonge bier moet, afhankelijk van de gewenste smaak, vier tot 
zes weken rusten. Het bevat nog wat vergistbaar extract. Ook is 
een gedeelte van de gist zelf achtergebleven. Hierdoor gaat de 
koolzuurproduktie door, zij het in een laag tempo door de lage 
temperatuur. Het navergisten gaat langzaam, hetgeen de smaak 


alleen maar ten goede komt. 
Filtreren 


Vroeger werd bier uit stenen kruiken of tinnen kroezen gedronken. 
Toen hoefde het bier niet helder te zijn. Tegenwoordig drinkt 
men bier uit glazen en verlangt men een helder biertje. Alvorens 
het bier naar de bottelarij wordt gepompt passeert het een 
zogenaamd kiezelgoerfilter. Alle deeltjes die het bier 
vertroebelen blijven achter op het filterbed. Dit filterbed 


wordt gevormd door de fijne kiezelgoer. 
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Verpakken 


Nadat het brouwproces is voltooid en het bier is gefiltreerd, 
kan het bier in de bottelarij worden verpakt. Het bier kan 
worden gebotteld in flessen, blikken of fusten. Per verpakkings- 
materiaal staan hiertoe één of meerdere colonnes in de 


bottelarij. 


Een colonne bestaat uit verschillende machines die door middel 
van transportbanden met elkaar in verbinding staan. Tot die 
machines behoren onder andere een uitpak-, Élessenspoel- en een 
krattenwasmachine, een vuller, een pasteur, een etiketteer- en 
een inpakmachine. Tevens vinden controles plaats, zoals op 


reinheid van de flessen en op de vulhoogte. 


HET BROUWPROCES 
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Aanleiding 


De energieproblematiek in het begin van de jaren tachtig heeft 
geleid tot een algemene herbezinning op het energieverbruik binnen 
Heineken. Ten eerste bleven de ernergieprijzen aanzienlijk stijgen 
wat de besparing op het energieverbruik actueel maakte. Om het 
effect van energiebesparingsvoorstellen te kunnen bepalen, is een 
goed inzicht in het stoom- en elektriciteitsverbruik van de 
brouwerij nodig. 

Ten tweede werd Heineken geconfronteerd met de mogelijkheid dat het 
verbruik van aardgas ten behoeve van ondervuringsdoeleinden moest 
worden afgebouwd, Dit maakte niet alleen besparing van het 
stoomverbruik actueel, maar ook het bestuderen van de mogelijkheid 
om in eigen beheer elektriciteit op te wekken met behulp van een 
warmtekrachtinstallatie, Immers door warmte-kracht koppeling wordt 
het rendement van het aardgasverbruik zodanig verhoogd, dat aan de 
aardgaslevering geen grens meer gesteld wordt. 

Om nu de aan zo'n installatie te stellen eisen te bepalen is 
inzicht nodig in de gelijktijdigheid van de stroom- en 


elektriciteitsvraag van de brouwerij. 


Zo'n herbezinning op het energieverbruik vereiste dus een goed 
inzicht in het hele energiegebeuren van de brouwerij. Vanwege het 
dynamische karakter van het verloop van de energieverbruiken en 
vanwege het verlangde inzicht in hun onderlinge samenhang als 
functie van de tijd, werd besloten een simulatiemodel van de 


energieverbruikers van de Heineken brouwerij te Zoeterwoude te 


maken. 
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AANLEIDING 


DE ENERGIEPROBLEMATIEK 


— GESTEGEN ENERGIEPRIJZEN 


— AFBOUW AARDGASLEVERING 


DOELSTELLING 


HET VERKRIJGEN VAN FUNDAMENTEEL INZICHT 
IN HOE DE VERSCHILLENDE UTILITYSTROMEN 
IN HUN ONDERLINGE SAMENHANG ALS FUNCTIE 
VAN DE TĲD VERLOPEN. 








(ENERGIE BESPAREN) 


(WARMTE /KRACHT STUDIE) 
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Doelstelling 


De doelstelling, waaraan het vervaardigen van een simulatiemodel 


van de energieverbruikers in de brouwerij ten grondslag ligt, luidt: 


Het verkrijgen van fundamenteel inzicht in hoe de verschillende 
utility stromen in hun onderlinge samenhang als functie van de 


tijd verlopen. 


| 





4,5. 


Verwachtingen/Toepassingen 


Bij de start van het project had men verschillende verwachtingen 


van het simulatiemodel en dacht men aan uiteenlopende toepassingen, 


Hieronder volgt een - niet volledige - opsomming van deze 


verwachtingen en toepassingen, waarbij de met een (*) gemerkte 


verwachtingen/toepassingen inderdaad door het huidige model 


gerealiseerd kunnen worden. 


= Het model moet ondersteuning kunnen verlenen bij: 


— Met 


— Met 


de Warmte-Kracht studie voor de brouwerij te Zoeterwoude (*); 
het bepalen van te installeren utility capaciteiten bij 


uitbreiding van de produktiecapaciteit van de brouwerij. 


het model moet het effect kunnen worden bepaald van: 

het nemen van energiebesparingsmaatregelen binnen de 
verschillende produktieprocessen, bijvoorbeeld het toepassen 
van dampcompressie bij het wort koken (*); 

het wijzigen van één of meerdere produktieprocessen, 
bijvoorbeeld bij het overgaan op zwaarder brouwen, waardoor 
later in het proces verdunningswater nodig is (*); 

pieken in de energieverbruiken afvlakken door gerichte "peak 


shaving" toe te passen. 


het model moeten de energieverbruiken van verschillende 


situaties met elkaar kunnen worden vergeleken, zoals van: 


een periode waarin weinig wordt geproduceerd met een drukke 
produktieperiode (*); 

een periode met een lage buitentemperatuur (de winter) met 
een hoge buitentemperatuur (de zomer) (*); 


het weekend met de doordeweekse dagen (*). 
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VERWACHTINGEN / TOEPASSINGEN 
— ONDERSTEUNING VERLENEN BĲ 


o W/K STUDIE Z/WOUDE 
o BEPALEN TE INSTALLEREN UTILITY CAPACITEITEN 


— EFFECT BEPALEN VAN 
o ENERGIEBESPARINGSMAATREGELEN 
o WIJZIGINGEN IN PRODUKTIEPROCES 
o GERICHTE "PEAK SHAVING' TOEPASSEN 


— VERGELIJKEN VAN VERSCHILLENDE SITUATIES 
o DRUKKE MET RUSTIGE PERIODE 
o KOUDE MET WARME PERIODE 
o WEEKEND MET WERKDAGEN 
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SIMULATIETAAL PROSIM 


MODELLEER TAAL 

ACHTERGROND TAAL PL/1 

GECOMBINEERDE DISCRETE-CONTINUE SIMULATIE 
PROCES-— EN ACTIVITEITENBESCHRIJVINGEN 
DEBUGGING EN TEST FACILITEITEN 

SIMULATIE HULPMIDDELEN 


SYS TEEMOMGEVING 


IBM MAINFRAME 

DOS OPERATING SYSTEM 

BATCHGEWIJZE VERWERKING 

ONTWIKKELING EN PRODUCTIE OP DEZELFDE COMPUTER 
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Simulatietaal PROSIM 


Het computersimulatiemodel is geschreven in de simulatietaal 
PROSIM, PROSIM staat voor PROcess SIMulation. PROSIM is ontwikkeld 
op de TH Delft en wordt gedistribueerd door de firma Sierenberg & 
de Gans b.v. 

PROSIM is een modelleertaal, welke zelf in PL/l is geschreven. 
Hierdoor kunnen naast de PROSIM statements eveneens de meeste PL/1 
statements worden gebruikt. Anderzijds is slechts geringe kennis 
van PL/l nodig, voornamelijk voor het verzorgen van de in- en 


uitvoer van een model. 


PROSIM biedt faciliteiten voor discrete-continue simulatie, 
accepteert zowel proces- als activiteitenbeschrijvingen voor de 
verschillende gedefinieerde componenten en heeft als test en 
debugging faciliteiten de trace optie en een hoeveelheid messages, 
welke voor zich spreken. De trace optie vergemakkelijkt de 
verificatie van het model, doordat het alle gebeurtenissen die 


tijdens de simulatie optreden in chronologische volgorde laat 
Printen. 


Tenslotte heeft PROSIM een aantal simulatiehulpmiddelen, zoals : 


‚ proces control faciliteiten; 
* randomstreams (verschillende verdelingen mogelijk); 
. histogrammen, tabellen en plots; 


* wachtrijen en verzamelingen. 
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4.7. 


Systeemomgeving 


Tot augustus 1985 was PROSIM binnen Heineken alleen in de batch be- 
schikbaar. PROSIM draaide op een IBM mainframe onder het DOS operating 
system. Momenteel draait PROSIM zowel in de batch onder DOS, als in de 
foreground onder CMS, waarbij dàn gebruik wordt gemaakt van de OS 

PL/l compiler. 

De ontwikkeling van het Utility Stromen Simulatie computermodel heeft 
echter uitsluitend in de batch plaatsgevonden, Aangezien binnen 
Heineken voor ontwikkeling van software — en dus ook van simulatie- 
modellen - en voor het gebruik van volledig ontwikkelde en uitgeteste 
software produkten één en dezelfde computer wordt gebruikt, krijgt 
ontwikkeling een lagere prioriteit in de batch dan produktie. Dit 
werkt vertragend op de modelbouw voortgang. 

Met de huidige beschikbare foreground faciliteit kunnen nieuw te 


bouwen simulatiemodellen echter sneller worden ontwikkeld. 


Eindresultaat 


Over het uiteindelijk verkregen simulatiemodel kan het volgende 


worden opgemerkt, ten aanzien van : 


— Het totaal model : 


Het totaal model is toegespitst op de Heineken brouwerij te 
Zoeterwoude. Derhalve kan met het model bijvoorbeeld niet op 
eenvoudige wijze de energievragen van de brouwerij te Den Bosch 
worden gesimuleerd. Anderzijds verschaft het model wel inzicht in 
de energiestromen, maar slechts gedeeltelijk in andere utility 
stromen, zoals water en Co. 


— De model onderdelen : 
Verschillende onderdelen zijn verklarend gemodelleerd. Zo worden 


bijvoorbeeld de energieverbruiken tijdens het brouwen per brouwsel 


berekend en vervolgens gesommeerd. 
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Andere onderdelen van de brouwerij zijn bij gebrek aan 
gedetailleerde (meet-)gegevens als regressie-model in model 
gebracht, Het elektriciteitsverbruik van de afvalwaterzuivering 
wordt bijvoorbeeld met behulp van, middels regressie-analyse 
gevonden, coëfficiënten berekend aan de hand van gesimuleerde 


produkties in de brouwhuizen en de bottelarijen. 
Verificatie van het model : 


Met de door PROSIM geboden trace faciliteit is het model voldoende 
geverifieerd, Tevens waren natuurlijk het constateren van 
negatieve of extreem hoge energieverbruiken een duidelijke 


aanwijziging voor het nog niet goed Eunctioneren van het model. 
Validatie van het model : 


Het model is nog niet volledig gevalideerd. De Heineken brouwerij 
te Zoeterwoude bezit een zogenaamd Energie Meet Systeem (EMS) 
waarmee allerlei metingen aan de verschillende utility-verbruiken 
kunnen worden verricht, Helaas kunnen door het niet goed 
functioneren van de stoommeters, geen stoommetingen worden 
verricht. 

Het model kon wel worden gevalideerd naar totaal gasverbruik per 
hectoliter geproduceerd bier en idem voor het totale 
elektriciteitsverbruik. Hierbij toonde het model grote 
overeenkomsten met de werkelijke bedragen. 

Echter, ondanks het feit dat het model nog niet volledig is 
gevalideerd, kan het toch inzicht in de energieverbruiken 
verschaffen, door de uitkomsten van de simulatie als graadmeter en 


een tendens te beschouwen, 
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EINDRESULTAAT 


— TOTAAL MODEL 


o TOEGESPITST OP BROUWERIJ Z/WOUDE 
o VOORNAMELIJK DE ENERGIESTROMEN 






— MODEL ONDERDELEN 
o VERKLAREND 
o REGRESSIE 


— VERIFICATIE 
o M.B.V. TRACE FACILITEIT 


— VALIDATIE 


o M.B.V. ENERGIE MEET SYSTEEM 
o (NOG) NIET VOLLEDIG 
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Gebruik van het model 


Hieronder volgt een korte beschrijving van de belangrijkste invoer 
welke door het model wordt verlangd, en van de uitvoer welke indien 


gewenst = wordt geproduceerd, 


— Input : 


. Van de verschillende procesdelen de stoom=- en/of 
elektriciteitsvragen, 

: Voor beide brouwhuizen per week een produktieplan, waarin 
vermeld staat wanneer een volgend brouwsel moet worden 
ingemaischt (= beslagen). 

4 Voor iedere colonne per week hoeveel hectoliter van welke 
biersoort moet worden gebotteld. 

B Opgegeven moet worden welke onderdelen van de brouwerij 
buiten beschouwing gelaten moeten worden tijdens de 
simulatie. 

E Voor iedere te simuleren week wordt een waarde voor de 
buitentemperatuur verlangd. 

. Voor het genereren van storingen tijdens het brouwen en 
tijdens het bottelen dienen verschillende parameters te 


worden opgegeven. 


= Output : 


6 Verreweg de meest belangrijke en informatieve uitvoer is de 
Elektriciteit/Stoom matrix, kortweg E/S matrix genoemd. De 
E/S matrix verschaft informatie over de gelijktijdigheid van 
de opgetreden elektriciteits- en stoomvragen. Iedere rij 
representeert een stoomvraag interval en iedere kolom een 
elektriciteitsvraag interval. Ieder element van de E/s 
matrix geeft het percentage van de (simulatie)tijd weer dat 
de stoom- en elektriciteitsvraag zich binnen de omschreven 


intervallen hebben bevonden. 
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Tijdens de simulatie wordt bijgehouden hoe, ten gevolge van 
wijzigingen in de energievragen, van het ene element naar 
een ander element van de E/S matrix wordt gesprongen. Deze 
gegevens worden in de vorm van een overgangsmatrix 
opgeslagen. 

Zowel voor de stoom als de elektriciteitsvraag wordt de 
hoogste momentane waarde bijgehouden en de grootste 
belasting, respectievelijk aangeduid als piekverbruik en 
piekbelasting. De belasting komt overeen met de gemiddelde 
vraag gedurende een bepaald tijdbestek (voor stoom een uur, 
voor elektriciteit een kwartier). 

Van ieder onderdeel van de brouwerij worden de energievragen 
bijgehouden en geïntegreerd, zodat ook de verbruiken bekend 


zijn. Deze verbruiken van de brouwerij-onderdelen worden 


o.a. gebruikt voor de validatie van het model. 






GEBRUIK VAN HET MODEL 





INPUT 
— ENERGIEVERBRUIKEN PROCESDELEN 
— PRODUCTIE PLAN 
— SITUATIE KARAKTERISTIEKEN 
— STORINGS KARAKTERISTIEKEN 


OUTPUT 

— E/S MATRIX 

— OVERGANGSMATRIX 
— PIEKVERBRUIKEN 
— ENERGIEVRAGEN EN —VERBRUIKEN 
PER BROUWERIJ ONDERDEEL 
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4.9. 


Berekeningen met E/S matrix 


Een E/S matrix geeft van een bepaalde gesimuleerde situatie de 
opgetreden energievragen weer. Indien men voor deze situatie de 
economische efficiëntie van een specifieke W/K-installatie wil 
bepalen, dan heeft men naast de E/S matrix zowel gegevens over de 
W/K-installatie als over de energieprijzen nodig. Van de 
W/K-installatie moet men gegevens hebben over de elektriciteit- 


opwekking en over het gasverbruik als functie van de stoomvraag. 


Naast de ontwikkeling van het simulatiemodel is afzonderlijke 
Programmatuur geschreven, waarmee, op grond van enerzijds een E/S 
matrix en anderzijds gegevens over de te beschouwen W/K-installatie 
en gegevens over de energieprijzen, de energiekosten op jaarbasis 
worden berekend. 

Het programma optimaliseert naar kosten, door voor ieder element 
van de E/S matrix te bepalen wat het goedkoopst is : geen gebruik 
maken van W/K of juist wel en indien ja, met l, 2 of 3 gasturbines. 
Hierbij wordt verondersteld dat altijd aan de stoomvraag wordt 
voldaan en dat afhankelijk van de hoeveelheid opgewekte 
elektriciteit en de elektriciteitsvraag, wordt berekend hoeveel 
elektriciteit moet worden ingekocht van of juist kan worden 
teruggeleverd aan het net. 

Als uitvoer wordt een financieel en verbruiksoverzicht verkregen. 
Hieruit valt bijvoorbeeld af te lezen hoeveel elektriciteit is 


teruggeleverd aan het net en hoeveel geld dat heeft opgeleverd. 


Dit afzonderlijke programma is geschreven in de interpretatieve 
taal APL. Hierdoor heeft de gebruiker de mogelijkheid direct het 
gevolg te constateren van een wijziging in bijvoorbeeld de gas 


inkoopprijs, door een nieuwe prijs in te tikken. 
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Het programma vereist o.a. een: E/S matrix als invoer. Zo'n E/S 
matrix kan verkregen worden door een simulatierun met het model uit 
te voeren. Anderzijds kan de E/S matrix ook worden samengesteld aan 
de hand van in de werkelijkheid verrichte totaal metingen aan de 


energievragen. 












BEREKENINGEN MET E/S MATRIX 


INVOER GEGEVENS 
SIMULATIEMODEL 









SIMULATIE 
UTILITY STROMEN 


METINGEN 
ENERGIEVERBRUIK 
E/S MATRIX ENERGIEPRIJZEN 
GEGEVENS W/K 


OPTIMALISATIE 
GEBRUIK W/K 


KOSTEN & 
VERBRUIKEN 
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4.10. Conclusies 


Voor het project "Simulatiemodel van de Utility Stromen in een 


Brouwerij" kan worden geconcludeerd : 


t.a.v. de doelstelling : 


Met het model wordt middels verschillende uitvoer inzicht in 
de energiestromen verkregen, zowel in de verbruiken als in 
het verloop van de vragen in hun onderlinge samenhang als 
functie van de tijd. 

Het model kan niet direct worden toegepast op andere 
vestigingen dan de brouwerij Zoeterwoude. Hiervoor moet 
enerzijds het model worden aangepast en moeten anderzijds 
opnieuw gegevens over energievragen, produktiecapaciteiten 


e.d. worden verzameld. 


t.a.v. de gevolgde methodiek : 


Het model is ontstaan door een onderdeel van de brouwerij te 
modelleren en vervolgens dit deelmodel te koppelen aan de 
reeds in model gebrachte onderdelen, de "bottom-up" methode 
als het ware, 

Hierdoor is pas in het laatste stadium een totaal model 
beschikbaar. Een "top-down" modellering verdient echter de 
voorkeur. Tijdens ieder stadium is dan een totaal model 
voorhanden, waarvan de modellering steeds gedetailleerder en 
de uitkomsten steeds betrouwbaarder worden. 

Wellicht een cliché binnen het onderwerp simulatie : het 
verzamelen van alle gegevens, niet alleen over de 
energieverbruiken van procesonderdelen, maar ook over hoe 
Processen binnen de brouwerij verlopen, heeft de meeste tijd 
in beslag genomen. 

In verband met de validatie van het model kun je zogezegd 
niet vroeg genoeg beginnen met het verrichten van 
praktijkmetingen. 

Het ontwikkelen van een simulatiemodel in een omgeving waar 
tevens produktie draait met een veel hogere prioriteit, 
heeft een duidelijk vertragende invloed. Om dit te verhelpen 
kan een eigen mini- of micro=computer voor de afdeling 


uitkomst bieden. 
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CONCLUSIES 
T.A.V. 
— DOELSTELLING 


o INZICHT IN ENERGIESTROMEN VERKREGEN 
o TOEPASSING OP ANDERE VESTIGINGEN VEREIST 
. MODEL AANPASSINGEN 


. GEGEVENS VERZAMELEN 
METHODIEK 


o “TOP DOWN!" MODELLERING VERDIENT VOORKEUR 

o GEGEVENS VERGARING VORMT BOTTLE-NECK 

o ONTWIKKELEN IN PRODUCTIEOMGEVING VERLOOPT 
MOEIZAAM 
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5. MANIP : COMPUTER AIDED ENGINEERING 
BIJ HET ONTWERP VAN RUIMTEVAARTUIGEN 


R. Kraak 
BSO/Automation Technology bv 


Introductie 
MANIP is een interactief modelling en simulatie systeem dat de 


ingenieur helpt bij het ontwerpen van ruimtevaartuigen waarbij met 


name gelet wordt op het thermodynamische gedrag. 
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Inleiding 


MANIP is een modelling en simulatie systeem dat door BSO wordt 
ontwikkeld in opdracht van de Thermal and Environmental Control 
Section van ESTEC, het European Space Technology Centre. Hier houdt 
men zich met name bezig met het ontwerpen van thermische controle 
systemen voor satellieten. Een belangrijke plaats wordt ingenomen 
door het bestuderen van het gedrag van dergelijke systemen onder 
verschillende omstandigheden, voornamelijk door middel van 


simulatie technieken. 


Het doel van MANIP is te voorzien in de behoefte aan een 
interactief systeem dat snelle aanpassingen van het model toestaat, 
en dat de ingenieur voor een belangrijk deel verlost van 
programmeeractiviteiten, Bovendien dient MANIP te kunnen inspelen 
op te verwachten ontwikkelingen op hardware-gebied, en dient dus 


een hoge graad van overdraagbaarheid te bezitten. 


MANIP wordt geheel ontwikkeld op de interne rekenfaciliteiten van 
BSO/AT. De specificatie en architectureel ontwerp fase werd 
afgerond aan het eind van 1983. De eerste versie zal worden 


opgeleverd aan het begin van 1986. 
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Een overzicht van MANIP 


Op het hoogste niveau heeft MANIP een structuur die volledig 


aansluit bij de ontwerpcyclus, en wel door de volgende onderdelen: 


— modelling : het inbrengen en veranderen van het model; 
— simulatie : het besturen van experimenten; 
— analyse : het bestuderen van de resultaten van een experiment; 


- rapportage : het documenteren van de gehele cyclus. 


Het voordeel van de geïntegreerde aanpak van de cyclus, die MANIP 
beoogt, zou teniet worden gedaan als deze onderdelen slechts 
sequentieel uitgevoerd zouden kunnen worden. MANIP voorziet dan ook 
in het gelijktijdig uitvoeren van meerdere onderdelen, zoals het 
bekijken van resultaten terwijl de simulatie bezig is, en het 
rapporteren van een verandering in het model terwijl deze wordt 


aangebracht, enz. 


Verdere interactiviteit wordt verkregen door mogelijkheden om de 
simulatie te onderbreken, in het model gedefinieerde parameters een 
andere waarde te geven, en verder te gaan, of juist opnieuw te 


beginnen. 


Bij het analyseren van de resultaten tenslotte, kunnen ook 
resultaten van andere experimenten worden betrokken. Dit maakt het 
mogelijk om bijvoorbeeld parameterstudies over meerdere 


experimenten te doen. 
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5.3. 


De werkcyclus van de ontwerper 


Eén van de uitganspunten bij het opstellen van de specificaties 
voor MANIP is geweest, dat de gebruiker met één systeem in staat 
moet zijn het volledige ontwerpproces te doorlopen. Een dergelijk 
proces bestaat in het algemeen uit een aantal studies van 


verschillende aspecten of onderdelen van het ontwerp. 


Iedere studie begint met het definiëren van een model, het 
simuleren van het gedrag van het model, en het analyseren van de 
resultaten van de simulatie. Aan de hand van deze resultaten wordt 
het ontwerp bijgesteld, waarna een nieuwe simulatie volgt, 
enzovoorts. Als uiteindelijk een bevredigend resultaat is bereikt, 


wordt over de hele cyclus gerapporteerd. (fig. 1.) 


Het onderwerpen van een versie van het model aan een simulatie 
wordt een experiment genoemd. In een experiment wordt dus het 
gedrag van een model onder invloed van externe factoren 
gesimuleerd. Deze externe factoren zijn vastgelegd in een zogenaamd 


scenario. 


In een experimentele omgeving kan verwacht worden, dat het aantal 
iteraties in de ontwerpcyclus groot is. Dit kan leiden tot 
problemen wat betreft de opslag en de overzichtelijkheid. Toch zal 
men in het algemeen veel waarde hechten aan de reproduceerbaarheid 
van experimenten. Bij het ontwerpen van MANIP is juist hiermee 


rekening gehouden. 


EN ID 


Figuur l : De ontwerpcyclus 
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Het "Gebruikersmodel" 


Een experiment kan beschouwd worden als een zwarte doos, waar een 
hoeveelheid informatie aan wordt toegevoegd, en waar een 
hoeveelheid resultaten uitkomt. Uit de eis voor reproduceerbaarheid 
van de resultaten volgt, dat er een één-op-één afbeelding moet zijn 
tussen een (versie van een} model, en de resultaten. In MANIP is 


een model dan ook gedefinieerd als: 


“alle informatie die nodig is om de bijbehorende resultaten voort 


te kunnen brengen". 


Een MANIP model kan, naar de gebruiker toe, worden gepresenteerd 
als in fig. 2. Het kan op verschillende manieren worden 
onderverdeeld. De meest voor de hand liggende verdeling is die naar 


aard van de data: 


— Wiskundig model. Dit bevat informatie over het gedrag van 
onderdelen van het model, in de vorm van statements van een 
simulatietaal, die speciaal voor dit doel is ontwikkeld: de 
Model Description Language of MDL. Ieder element van dit deel 
van het model heeft een aantal parameters, waarvan de waarde 
wordt bepaald door statements. In principe kan iedere parameter 
door een functie worden bepaald. De warmtecapaciteit van 
materiaal, bijvoorbeeld, die mede bepalend is voor de 
temperatuurverdeling, kan afhankelijk zijn van de temperatuur: 


Gelijksoortige elementen kunnen worden ondergebracht in klassen. 
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Figuur 2 : Het gebruikersmodel 
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- Geometrisch model. In de ruimte wordt de warmte uitwisseling 
tussen lichamen voornamelijk bepaald door stralingsuitwisseling, 
dit wil zeggen door de geometrische eigenschappen van de 
lichamen. Het geometrische model speelt voor deze toepassing dan 
ook een belangrijke rol. De geometrie wordt ingevoerd met behulp 
van een grafische terminal. Uitgaande van een bibliotheek met 
elementaire figuren kunnen ingewikkelde constructies worden 


samengesteld. 


- "Meta-model". Dit bevat hoofdzakelijk informatie over de rest 
van het model, zoals lijsten van onderdelen die bij elkaar 
horen, selecties van data, enz. Een bijzonderheid is de 


aanwezigheid van het scenario in het model. 


Het model kan ook worden opgesplitst in een functioneel en een 
beschrijvend gebied. Het functionele gebied bevat alle data die 
direct een rol spelen tijdens de simulatie. Het beschrijvende 
gebied bevat achtergrondinformatie, waarnaar wel kan worden 
verwezen. Een voorbeeld is een tabel met materialen en hun 
eigenschappen. Deze wordt wel gebruikt als referentie (dit 
onderdeel is van dit materiaal gemaakt), maar wordt niet mee 


gesimuleerd. 


Een derde verdeling is van groot belang. In zijn "kale" vorm heeft 
MANIP geen kennis van de wereld. Dit heeft het voordeel dat MANIP 
in principe kan worden gebruikt voor velerlei doeleinden, maar ook 
het nadeel dat veel informatie moet worden ingevoerd om een 
relatief eenvoudig model te definiëren. Om dit te voorkomen bestaat 
een MANIP model uit een "systeemmodel" en een "gebruikersmodel". 
Het systeemmodel is in feite een geconfigureerd deel van het 
systeem. Het bevat algemene definities en, bijvoorbeeld, 
natuurwetten die van belang zijn voor een bepaald 
toepassingsgebied. Het systeemmodel is voor iedere gebruiker 


toegankelijk, maar alleen te veranderen door een beheerder. 
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Figuur 3 : Een voorbeeld van een element definitie 


EEN VOORBEELD VAN EEN ELEMENTDEFINITIE 


ELEMENT: T1 TYPE: ACTIVE CLASS: THERMOSTAT 
PARAMETER NAME: |DOMAIN: DEFINITION: 


SENSE TEMP TEMPERATURE POINTTEMP (L1) 
LOW THRESHOLD | TEMPERATURE 

HIGH THRESHOLD | TEMPERATURE 

STATE SWITCH 


STATEMENTS: 


1: WHENEVER SENSE TEMP : <LOW THRESHOLD DO STATE := ON 
ENDWHEN 

2: WHENEVER SENSE TEMP : >HIGH THRESHOLD DO STATE := OFF 
ENDWHEN 
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Interne representatie van een model 


Alle model informatie wordt intern opgeslagen in de vorm van een 
relationele database. Deze is op zichzelf configureerbaar met be- 
hulp van een speciale taal, zodat aanpassing van datastructuren 
eenvoudig is. Een groot deel van de database wordt in beslag genomen 
door vaste relaties. Hierin wordt bijvoorbeeld de geometrische 


informatie opgeslagen, maar ook de interne administratie. 


De interne database is in feite een soort "werkgebied", waartoe een 
groot aantal MANIP processen toegang hebben. Het aanmaken en terug- 
halen van data gebeurt door middel van een klein aantal krachtige 


primitieve functies. 


Externe database 


De externe database geeft de faciliteit op vroegere modellen terug 
te vallen, vorige resultaten te inspecteren en resulaten te verge- 
lijken. Het dient ook als uitwisselmedium tussen de verschillende 
MANIP systemen. 

De structuur van de externe database is een deelverzameling van de 
interne database, in feite de modellen en de resultaten. Alle 
hulpstructuren die een snelle ontwerp cyclus mogelijk maken, zijn 


slechts in de interne database aanwezig. 


De toegang tot het model wordt verzorgd door zogenaamde "views". Een 
view is een serie query-commando's die interactief wordt opgebouwd 
volgens het "you see what you get” principe. Elementen van het wiskun- 
dige model worden gepresenteerd in de vorm van een spread-sheet, die 


van het geometrische model in de vorm van 3-dimensionale graphics. 


Een speciale plaats in de database wordt ingenomen door de relatie 
klasse-element-parameter. Zoals reeds opgemerkt, worden deze 
parameters gedefinieerd door één of meerdere statements van de Model 
Description Language. Deze statements worden als tekst in de database 
opgeslagen. De waarden die uit de definities volgen worden opgeslagen 
in een speciale relatie: de state-vector. Deze speelt een centrale 
rol in de simulatie. Omdat de state-vector immers de actuele waarden 
van alle parameters bevat, beschrijft zij exact de toestand van het 
model op ieder moment. 


ERF 








De MDL statements worden door een compiler omgezet in zogenaamde 
mini=processen. Deze kunnen worden beschouwd als relaties tussen de 
elementen van de state=vector (fig. 4). Er zijn mini-processen die 
op één state-vector werken, maar ook zijn er mini=processen die, 
uitgaande van een state-vector, elementen van een volgende 


state-vector berekenen........ 


MDL vertoont veel meer gelijkenis met moderne kunstmatige 
intelligentietalen zoals PROLOG dan met de gebruikelijke 
computertalen, die een sequentie van opdrachten vormen. 

Voor de gebruiker heeft dit tot gevolg dat de volgorde van de MDL 
statements niet van belang is. Ook kan het MANIP systeem zelf 
uitmaken welke miniprocessen tegelijkertijd kunnen draaien, zodat 


met voordeel gebruik gemaakt kan worden van de 5e generatie 


computers met hun parallel proces faciliteiten. 
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Simulatie 


Een simulatie kan worden beschouwd als een serie opeenvolgende 
state-vectors. Tijdens de simulatie kan naar de resultaten worden 
gekeken met behulp van een monitor. Dit is een lijst met 
query-commando's die veel overeenkomst vertoont met een view. 
Alleen het domein is anders: in plaats van uit de database wordt de 


data uit de laatste (of een willekeurige) state-vector gehaald. 


Door middel van interrupt kan de gebruiker tijdens de simulatie 
ingrijpen. De simulatie kan bijvoorbeeld tijdelijk worden stopgezet 
om bepaalde state-vector elementen een andere waarde te geven, of 


om de monitor definitie te veranderen, enzovoorts. 


Deze interactieve aspecten hebben tot gevolg dat het scenario pas 
is gedefinieerd als de simulatie is afgelopen. Het scenario is 
immers de som van een eventuele lijst met commando's die al 
aanwezig was (bijvoorbeeld het scenario van een vorige simulatie), 
en de interactieve commando's. Deze oplossing garandeert de 


reproduceerbaarheid. 


= JO 





SIMULATION 


SCENARIO 
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5.7. 


Resultaat-analyse 


Alle eind- en tussenresultaten van een simulatie kunnen worden 
opgeslagen in een zogenaamde resultaten-ruimte. Dit is de ruimte 
die wordt opgespannen door de serie state-vectors die tijdens de 


simulatie worden gegenereerd. 


Door de resultaten ruimtes van verschillende simulaties te 
combineren ontstaat in feite een 3-dimensionale ruimte (fig. 7). 
Het resultaten-analyse gedeelte van MANIP bevat een aantal Éuncties 
waarmee "doorsnedes" van deze ruimte kunnen worden gemaakt. Deze 
kunnen worden gerepresenteerd in de vorm van tabellen, maar ook als 


grafieken. 


Rappor tage 


Ten slotte biedt MANIP de mogelijkheid om op ieder gewenst moment 
een tekstverwerkingspakket op te roepen, om de rapportage te 


verzorgen. ie 


Samenvatting 


MANIP is een modelling en simulatiesysteem dat de ingenieur bij 
alle fasen van zijn ontwerpcyclus ondersteunt. Door de mogelijkheid 
om meerdere functies tegelijkertijd uit te voeren is MANIP 
krachtiger dan een combinatie van gereedschappen voor iedere fase 
apart. MANIP biedt een grote mate van flexibiliteit aan de 


gebruiker, terwijl toch de resultaten reproduceerbaar zijn. 


SecBls 
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THREE--DIMENSIONAL REPRESENTATION Of THE RESULTS SET 
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Verantwoording: 

BSO/Automation Technology bv voert het MANIP project uit in opdracht van 
het European Space Research and Technology Centre (ESTEC) te Noordwijk, 
voor wiens medewerking de auteur zeer erkentelijk is. De verantwoorde- 
lijkheid voor de inhoud van dit artikel ligt echter volledig bij de 
auteur. 
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MODEL VALIDATIE IN EEN MODERNE 
INTERACTIEVE SIMULATIE OMGEVING 


A. v.d. Horst 
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Introductie 
Aan de hand van de ervaring opgedaan bij het ontwerpen van MANIP 


worden een aantal algemene conclusies getrokken over de moderne 


simulatie omgeving en wat daarvan te verwachten is. 
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6.1. 


Inleiding 


Een van de meest belangrijke ontdekkingen van de twintigste eeuw is 
dat er fundamentele beperkingen zijn aan wat met wiskunde kan 
worden bereikt. De werkelijkheid bestaat niet uit een starre keten 
van oorzaken en gevolgen, maar uit een organisch geheel van 
evenwichten en tegenstellingen, waarbij het er op elk moment om 
gaat de belangrijkste ontwikkeling te vinden en dat is degene die 
de ontwikkeling bepaalt. Er werden mechanismen ontdekt die benut 
konden worden om de werkelijkheid te analyseren op een manier zoals 
de mens dat doet, door een beeld (kopie) van de werkelijkheid te 
laten ontwikkelen. 

Deze ontdekkingen, de lambda calculus en de Turing machine, leidden 
al snel tot de vraag: 

"Kan een dergelijk mechanisme zichzelf analyseren zoals de mens 
zichzelf kan analyseren?". Preciezer gesteld in simulatietermen : 
“Kan het resultaat van een simulatie kort gesloten worden, kan het 
resultaat van een simulatie voorspeld worden aan de hand van de 
invoer?" 

Het antwoord gegeven door Goedel, Turing, Kleene en anderen was 
neen. 

Dit bevestigt simulatie als een middel dat fundamenteel 
noodzakelijk is om kennis binnen bereik te brengen die op geen 
enkele andere manier verkregen kan worden. 

Zoals altijd gaat de ontwikkeling van de wetenschap hand in hand 
met die van de techniek. Hier vormen de simulatie en de computer de 
noodzakelijke voorwaarden voor elkaars ontwikkeling. 

Simulatie is de techniek, de wetenschap en de filosofie van de 


tweede helft van de twintigste eeuw. 


BĲ = 


6.2. Declaratieve versus imperatieve talen 


| Een simulatie is in wezen een tijdreeks van wetmatig uit elkaar 
| voortvloeiende toestanden waarbij soms de wetten van het toeval 
| gelden. Het ligt voor de hand de toestand te beschrijven met 

| voldoende getallen van voldoende precisie en opdrachten te 


prepareren voor de computer. Dit werkt. 


Zelfs de eenvoudigste computer (de Turing machine) is voldoende om 
te simuleren m.a.w. elke computertaal was een simulatietaal. 
Voordat we nu al onze modellen in FORTRAN gaan schrijven, moeten we 


enige nadelen van de conventionele machinetalen bekijken. 


Beschouw het simpele model van een rechthoek. 

















A RECTANGLE HAS A WIDTH, LENGTH 
AND AREA, 


THE AREA IS THE PRODUCT OF THE 
LENGTH AND THE WIDTH 


IT IS KNOWN THAT 


LENGTH EQUALS 2 
WIDTH EQUALS 2 
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(FORTRAN) 
REAL LENGTH, WIDTH, AREA 
AREA = LENGTH «* WIDTH 


LENGTH 
WIDTH 


2 
J 
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Het model is statisch en tijdonafhankelijk. Desondanks is de 
volgorde van de FORTRAN statements fout en leidt tot een onjuist 


beeld. 


Voor andere praktische simulatie problemen geven klassieke 


‘computertalen geen houvast om het probleem aan te pakken. 


ZEN 
WAITING ROOM 
ON THE AVERAGE EACH HOUR 


8 PATIENTS ENTER THE 
WAITING ROOM OF DOCTOR A 
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(FORTRAN WAITING ROOM PROBLEM) 


DIFFICULT EVEN TO AN EXPERT 
REQUIRES CONSTRUCTION OF A 
WAY TO PRESENT KNOWLEDGE 
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COOLING SPHERE PROBLEM 


THE COOLING DOWN OF A CONDUCTING 
SPHERE IS PROPORTIONAL TO ITS 
AREA AND THE FOURTH POWER OF ITS 
TEMPERATURE. 
THE PROPORTIONALITY CONSTANT IS 10 
WE KNOW THAT 
THE AREA IS 1 
THE TEMPERATURE IS NOW 27 C 
THE HEAT CAPACITY IS 25 


9 
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6.3. 


Declaratieve talen in de praktijk 


Het wordt tijd terug te komen op de andere fundamentele mechanismen 
dat leidde tot het simulatie tijdperk, namelijk de lambda calculus. 
Deze lambda calculus is de wortel van de kunstmatige intelligentie 

talen zoals LISP en met name PROLOG, dat zich vooral in Japan de 


laatste tijd snel verbreidt. 


Dergelijke talen hebben de eigenschap van de lambda calculus 
behouden, dat de betekenis van een verzameling uitspraken niet 


afhangt van de volgorde. 


PROLOG "PROGRAM" 


IF SOMEONE IS A GREEK, HE IS A HUMAN 


IF SOMEONE IS A HUMAN, HE IS MORTAL 


SOCRATES IS A GREEK 


IF SOMEONE IS DUTCH AND IS INTELLIGENT, 
HE IS A HUMAN 


JAN IS A DUTCHMAN 
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Je kunt de vraag stellen: welke mensen zijn er. 


We hoeven niet zo ver te zoeken voor een declaratieve taal. Het 
zogeheten "spreadsheet" dat op vrijwel alle personal computers in 


vele vormen bestaat is een voorbeeld van een declaratieve taal. 






SPREAD SHEET VALUES 


Î 2 3 
LENGTH | WIDTH | AREA 
2.00000f 5.00000f 6.00000 
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SPREAD SHEET FORMULA'S 

















1 2 5 
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8 (20000 
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Het spreadsheet spreekt aan. Dit bedieningsgemak maakte het 
spreadsheet tot een van de inspiratiebronnen voor het MANIP systeem, 
We krijgen dus het volgende beeld van een declaratieve taal. 
De statements van een declaratieve taal zijn niet zozeer opdrachten 
die in volgorde uitgevoerd moeten worden, maar regels die de 


computer al dan niet en wellicht talloze malen toepast. 


De volgorde van de statements is niet van belang. Wanneer twee 
programma's worden samengevoegd of een programma wordt uitgebreid, 
voegt men de statements eenvoudig samen. 

Declaratieve talen zijn niet "natuurlijk" voor de gebruikelijke 
computers. 

Daarom vormen ze in het algemeen een zware belasting. Ook leidt een 
elementaire opdracht tot een onbepaalde hoeveelheid computer werk, 


soms weinig, vaak erg veel. 
Desondanks concluderen we ook met het oog op de ontwikkelingen op 


hardware gebied (parallel computing) dat declaratieve talen een 


kans moeten krijgen in simulatie. 
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6.4. De MANIP "Model Description Language" 


MANIP is bedoeld voor een ingenieurs omgeving, d.w.z. voor een 
simulatie zonder statistische aspecten, dus geen wachtkamer 


problemen e.d. 


Een typisch physisch systeem dat gesimuleerd kan worden is een 
vallend balletje. Op een bepaald moment raakt het balletje een 


vloer en keert de snelheid om. 


Dit kan beschreven worden met een stel wiskundige vergelijkingen, 
waaronder differentiaalvergelijkingen, aangevuld met een zogeheten 
"event mechnisme". (Omdat we niet met oneindig veel getallen kunnen 
werken, veronderstellen we dat partiële differentiaal 
vergelijkingen, m.b.v. een eindige elementen methode zijn omgezet 


in gewone differentiaal vergelijkingen). 


Uiteindelijk blijken 3 typen statements voldoende te zijn om 


dergelijke simulaties te doen. 


Allereerst hebben we de DEFINING statement. 
Een voorbeeld hiervan is 


area = length * width. 


Hiermede definiëren we area, we geven dus aan het systeem een 
regel, waarmee area uitgerekend kan worden als de andere twee 
bekend zijn. 

Omdat we echt gaan simuleren, d.w.z. de tijdontwikkeling van een 
systeem gaan bekijken, betekent dit veel meer dan in het 
spreadsheet voorbeeld, namelijk dat het op elk gegeven moment zo is. 
De variable namen mogen eindigen in een of meer "'" en hebben dan 


de gebruikelijke wiskundige betekenis van afgeleide. 


Voorbeeld: drag=-force = alfa * x' **2 


zB 
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Dit brengt ons op het tweede type statement: de INTEGRAL DEFINING 


statement. 


Bijvoorbeeld: 


x''= =g 


Dit is een DEFINING statement voor een variabele met naam x'', maar 
het is iets meer. Het vertelt het systeem namelijk ook dat x'' de 


afgeleide van x' is en x' de afgeleide van x. 


Het derde type, de WHEN statement geeft een regel over tijdstippen 
waarop een gebeurtenis plaatsvindt. Met nadruk gebruiken we het 
woord regel, omdat het systeem zelf moet uitzoeken of hij 


uitgevoerd moet worden, wanneer en hoeveel maal. 

WHEN x: 0.0 DO velocity: = = velocity ENDWHEN 

Deze drie typen statements blijken voldoende voor het simuleren van 
een groot aantal physische systemen zoals het opstijgen van een 


raket, een biljart, een lekkende kraan, de thermische huishouding 


van een kunstmaan, de vering van een auto, etc. 
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ELEMENT: ROCKET CLASS: 
PARAMETER DOMAIN DEFINITION 
HEIGHT FOOT 
THRUST POUND IF BURNING THEN 

3500.0 ELSE 0.0 
ENDIF (KG) 
BURNING BOOL 
DRAG KG M2 S-2 K*SIGN(HEIGHT') 
*HEIGHT'+*2 
K S2 —0,05 
MASS KG 300.0 
FUEL KG 
STATEMENT 


FUEL'=IF BURNING THEN —20.0 
ELSE 0.0 ENDIF 


HEIGHT"= 


g + (THRUST+DRAG)/(MASS+FUEL) 
WHEN FUEL:<O. DO BURNING:= 


FALSE ENDIF 
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De werking van de simulation executive, statisch. 


Om inzicht te krijgen in hoe de berekeningen in zijn werk gaan 
zullen we het voorbeeld van de raket iets nader bekijken. 

We beginnen met het doorrekenen van een statische situatie. 
Hierbij is MANIP eigenlijk een intelligent spreadsheet, die de 
berekeningen in de goede volgorde uitvoert en controleert of de 


gegevens voldoende en niet strijdig zijn. 


STATIC PART OF ROCKET MODEL 












ze 
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Om op een bepaalde tijd alle toestandsvariabelen te genereren is 
het nodig dat waarden voor BURNING, FUEL, HEIGHT en HEIGHT' gegeven 
zijn. Alle DEFINING statements zijn weergegeven met een cirkel en 
de data met de naam. 

We zien dus dat formule 2 niet kan toegepast worden voor formule 3 
is toegepast, maar wel kunnen de formules l, 4, 5 en 7 gelijktijdig 


uitgerekend worden. 
Het is duidelijk dat bepaalde waarden als uitgangspunten gegeven 


moeten zijn maar merk op dat het eigenlijk de beginvoorwaarden voor 


het probleem zijn. 
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De werking van de simulation executive, initialisatie 


De waarden voor BURNING, FUEL, HEIGHT en HEIGHT ' moeten opgegeven 
worden, voordat de eerste toestand volledig bepaald is, Daarna kan 
MANIP de toestand op volgende tijdstippen berekenen m.b.v. WHEN en 
statementents en INTEGRAL DEFINING statements. 

De waarden van FUEL, HEIGHT en HEIGHT’ kunnen bepaald worden door 
integratie. Dit kunnen we zien aan het feit dat de afgeleiden 
FUEL', HEIGHT' en HEIGHT'' in het systeem bestaan. Als er ook nog 
een definitie formule voor bijv. FUEL was zou dat tot conflicten 
(kunnen) leiden. Deze toestandsgrootheden zijn van het type 
INTEGRATED. Het integreren is ingebouwd in de taal en dus 


onzichtbaar. 


De variabele BURNING is van het type TRIGGERED, d.w.z. dat hij 
alleen door het uitvoeren van een WHEN statement veranderd. Het 
simuleren daarvan is eenvoudig. BURNING behoudt gewoon zijn waarden 
tot het moment van triggeren gepasseerd wordt. MANIP simuleert de 
raket tot precies het moment dat FUEL O0 geworden is, Vanaf dat 
moment gaat het verder met BURNING op FALSE. 


Merk op dat de variabele THRUST, hoewel hij parallel met BURNING 
verandert, DEFINED is en niet TRIGGERED. 


B => 





Resumerend 


Samen vormen deze definities en regels de wiskundige achtergrond 


van de 'engineering' simulatie. 


Wonderlijk genoeg is het niet de gewoonte dergelijke regels strak 
te formuleren. 

Een reden hiervoor is al eerder aangegeven. Dat is de sterke band 
die computertalen en simulatie talen hadden en hebben. 

Verder nemen constanten in alle andere simulatie talen een aparte 
plaats in. Dit leidt tot niet te verwaarlozen verwarring. Ook is 
het onderscheid tussen een toestands variabele van type TRIGGERED 
en een daarvan afhankelijke DEFINED variabele in vele talen vaag. 
Soms worden ook toestandsvariabelen die alleen op een event kunnen 


veranderen discreet genoemd, soms ook constant. 


THE THREE RULES OF 
MODEL CONSISTENCY 


EXACTLY ONE 'DEFINING' STATEMENT 
APPLIES TO A 'DEFINED' VARIABLE 
— NO 'DEFINING' STATEMENT APPLIES TO 
‘TRIGGERED' OR 'INTEGRATED' VARIABLES 
— NO 'WHEN' STATEMENT APPLIES TO 
‘DEFINED' VARIABLES 
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TRE- THREE - TYPES 
OF STATEMENTS 


DEFINING 
INTEGRAL DEFINING 
WHEN 
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THE. THREE IFES 
OF STATE VARIABLES 


DEFINED 
INTEGRATED 
TRIGGERED 
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wenn en tabe ned 


6.8. 


En verder ,.…. 
Bekijken we nog even figuur 7. 


De boom die gevormd wordt door de afhankelijkheden is breed maar 
niet hoog. 

Dit wordt pas echt duidelijk wanneer er ingewikkelder modellen in 
kaart gebracht worden. Dit betekent dat een verzameling statements 
vrij eenvoudig in groepen kunnen worden onderverdeeld die zonder 
interactie met de andere (bijna) door een processor afgehandeld 
kunnen worden. Voorlopige schatting geeft aan dat parallelle 
processing tot een factor 10 snelheidswinst leidt voor niet al te 
simpele modellen, terwijl voor echt ingewikkelde modellen dit tot 


een factor 100 aan snelheidswinst kan oplopen en meer. 


Vergelijk dit met de factor 10 die de limiet schijnt te zijn bij 


het vertalen van FORTRAN programma's voor parallel processoren. 
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6.9. 


Huidige MANIP implementatie 


Voorlopig moet MANIP echter efficient draaien op 'klassieke' 
computers. 

Hiervoor wordt gebruik gemaakt van het mechanisme dat detecteert of 
een statement met succes toegepast kan worden. Na het uitvoeren van 
een statement wordt er een vlag geïnspecteerd die de logische 'EN' 
is van alle vlaggen van in de formule gebruikte variabelen. Staat 
er een vlag, dan waren aìle inputs al uitgerekend en wordt de 
statement uitgevoerd. Zo niet dan wordt de statement later opniew 


geprobeerd, na alle andere. 


De volgorde van toepassing wordt onthouden voor de volgende keer, 


zodat geen mislukte executies meer optreden. 


Figuur 7 laat ons nog wat anders zien. Een dergelijk doorgeven van 
vlaggen als bij het bepalen van de geldigheid van het resultaat is 
ook nuttig voor optimalisatie. In de figuur is dit aangegeven door 
de dikte van de lijnen. De dikke lijnen hoeven slechts eenmaal voor 
de hele simulatie doorlopen te worden. 

Regel is dat de dikte van de uitgaande lijn overeenkomt met de 


dunste ingaande lijn. 
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De op normale dikte ge: 2kende lijnen kunnen wachten tot na het 
event dat BURNING op FALSE zet. 

Alleen DRAG en HEIGHT moeten telkens opnieuw uitgerekend worden. 
Vrijwel zonder extra werk (voor de computer, wel te verstaan) ten 
opzichte van het geldigheidscontrole die zojuist besproken werd, 
werd deze optimalisatie in het MANIP systeem ingebracht. Dit is 
o.a. gebaseerd op de mogelijkheid om 32 vlaggen (op een 32 bits 
computer) tegelijk te manipuleren, met hetzelfde gemak en snelheid 
als een. 

Vergeleken met figuur 7 MANIP zelfs nog een extra optimalisatie 


niveau dat intern in integratie algorithmen een rol speelt. 





FAILURE 


SUCCES 





BSO/Automation Technology Simdag 


Verantwoording: 
BSO/automation Technology bv voert het MANIP Project uit in opdracht van 


het European Space Research and Technology Centre (ESTEC) te Noordwijk, 
voor wiens medewerking de auteur zeer erkentelijk is. De verantwoorde- 


lijkheid voor de inhoud van dit artikel ligt echter volledig bij de 
auteur. 
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